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REMARKS 

Claims 1-9, 13 and 15-18 stand rejected under 35 USC 102 as being anticipated 
by Shiigi. The rejection is respect fully traversed. 

Rejection Under §102 Improper 

As a preliminary matter, applicants note that the rejection under 35 USC 102 is 
not proper. The theory under which the Office finds that the claimed invention is not 
patentable is based on a combination of two pieces of prior art — the Shiigi patent and 
the email capabilities of Hotmail. Applicant notes the following at p. 5 of the Office 
action: ^ 

The statement above [relative to the capabilities of Hotmail], combined with the 
material in the Shiigi reference, are the reasons the examiner stands by his 
rejection [emphasis added]. 

It is respectfully submitted that in order for a rejection to be proper under §102, 
the allegedly anticipating teachings must be found within the four comers of a single 
prior art document. Here, the Office action invokes two pieces of prior art in 
combination. Such a rejection is only properly made pursuant to 35 USC 103. 

Moreover, it is submitted that because applicants' claims stand rejected based 
(in part) on a newly cited prior art teachings, the examiner is not standing by the prior 
rejection, as the Office action states but, rather, entering a new rejection. 

The following remarks address the Office action as though the rejection had 
been made under §103 rather than § 102. 

Undated Reference to Hotmail is not Citable Prior Art 

The Office action has not provided any date on which the cited Hotmail 
functionality was first known or used publicly. The rejection is therefore not proper, as 
it does not make out a prima facie case that that invention was known in, or render 
obvious by, the art prior to applicants' invention or filing date. 
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The following remarks address the Office action based on the assumption— but 
only for purposes of discussion and without any admission — that the Hotmail 
functionality described in the Office action antedated applicants* invention. 

The Shiigi/Hotmail Combination 

Even if it were obvious to combine Shiigi with the Hotmail email capabilities 
noted in the Office action, and even if the Hotmail functionality preceded applicants' 
invention, the resulting combination is not the same as applicants' invention. 

Moreover, the resulting combination does not anticipate applicants' claims. 
Applicant agrees that when a Hotmail user opens up an email message that has 
an attached GIF file, the contents of the GIF file are automatically displayed below the 
typed message. Indeed, the undersigned replicated the Hotmail scenario set forth in the 
Office action by sending himself an email with a GIF attachment to a Hotmail account 
and then opening up the email using Hotmail. Attachment A shows the resulting 
Hotmail screen. The typed text is "This is a test." The GIF file was automatically 
opened by Hotmail and displayed below the text, the GIF file being an image of a 
handwritten signature of John Hancock. 

This mode o f operation of Hotmail does not anticipate applicants* claims, 
however. Applicants' claims state that the handwritten message image (e.g., a GIF file) 
and the typewritten message are transmitted in the same message field. More 
particularly, and in contrast to applicants' claimed invention, the only thing that the 
Hotmail program does is to open up the GIF attachment and display the file contents 
along with the text message. The actual transmission of the text and the image is in two 
separate message fields. This can clearly be seen from the fact that even though the GIF 
file is automatically opened and its contents displayed, the file still available for 
download as a separate entity. Note the displayed line "Attachment: handwriting.GIP in 
Attachment A. 
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The fact that the actual transmission of the text and the image is in two separate 
message fields can further been seen by enabling an option of Hotmail that allows one 
to see the full email header. (One does this by clicking on "Options/Mail Display 
Settings" and then clicking on the button labeled "Advanced" under the "Message 
Headers" heading.) When one does this for the sample email shown in Attachment A, 
what one sees is what is shown in Attachment B. 

Specifically, what is then displayed are the MIME (Multipurpose Internet Mail 
Extensions) headers for this message associated with the various message fields 
themselves. One can clearly see from Attachment B that the GIF file called 
"handwriting'* was sent to, and received by, Hotmail not in the same message field as 
the text, but in a separate message field. 

In particular, the text message field is introduced with a first header "Content- 
Type: text/plain," followed by the text itself. By contrast, the image field is introduced 
with a second header "Content-Type: image/=gif" followed by the name of the GIF file, 
i.e., name="handwriting.GIF." Clearly, then, the GIF file was not transmitted in the 
same message field as the text, but in a different field. 

Further explanation of MIME can be found in Attachment C, which was 
downloaded by the undersigned from the following web page: 

http://www.irailsbroadcastxom/eman^ 

Particular attention is directed to the following section, which begins at the 
bottom of the first page of Attachment C, specifically describing the automatic GIF-file- 
opening functionality pointed to in the Office action as being a feature of Hotmail: 

(MIME) Multipurpose Internet Mail Extensions 

MIME encoded messages consist of many parts-each part is allowed to be 
described in detail and some parts encoded. The purpose of MIME is to 
describe the many parts of an email message, such as attached sound files 
and images. 

MIME messages may include a plain text message and a GIF image-because 
GIF image is binary data consisting of 8 bit characters. To get the GIF image 
data to pass through the Internet-Base 64 is used to encode the data into 6-bit 
characters. 
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MIME is also used to annotate part of a message so that the receiving mail 
reader will know what data is stored in the message and process it optionally, 
i.e.; instead of listing the GIF file as a generic attachment-may automatically 
display it instead. 

This excerpt points out, first of all, that the purpose of MIME is to "describe the 
many parts of an email message, such as attached sound files and images [emphasis 
added]." Thus it can be seen in Attachment B that the two MIME headers therein 
separately describe the text field of the message and the GIF attachment field of the 
message. 

The fact that the GIF and text files are transmitted in separate message fields is 
further made clear from the statement in the quoted excerpt that GIF files sent as email 
attachments must be encoded in order to change their contents from 8-bit characters to 
6-bit characters. There is no indication that the text portion of the message is encoded 
along with the GIF file so, necessarily, they are in different message fields. Indeed, 
Attachment B makes clear that base64 encoding was applied only to the GIF 
attachment, per the entry "Content-Transfer-Encoding: base64" 

Moreover, the quoted excerpt points out that MIME annotates part of a message 
so that the receiving mail reader — in this case, the Hotmail program — will know what 
data is stored in the message and process it optionally. The quoted excerpt then gives 
the exact GIF example noted in the Office action wherein the mail reader ''may 
automatically display" the GIF file. This makes clear that the GIF file is a separate 
entity in the message as transmitted so that the mail reader, e.g., the Hotmail program 
can, indeed, access the attached GIF file and "process it optionally." 

This is exactly what is going on in Hotmail. The GIF file arrives as a separately 
encoded file — not in the text message field . The mail reader, i.e., the Hotmail program, 
automatically opens the GIF file and its contents. Indeed, the contents of the GIF file 
are displayed in the same area of the screen that the text message is displayed. But, 
again, the GIF file was transmitted in its own message field, contrary to applicants' 
claims. 
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The examiner's attention is also respectfully directed to the fourth page of 
Attachment C which shows an example of a message with a GIF file attachment that 
follows the same format as applicants* Hotmail example of Attachment B. 

In summary, then, although both the text message and GIF attachment may be 
displayed together in the same area of the Hotmail screen, the foregoing makes clear 
that this is merely a result of how the email reader — that is, the Hotmail program — has 
been configured to display t hose two fields. Nothing in any cited prior art shows or 
suggests that a typewritten reply message and a handwritten message image could or 
should be transmitted in the same message field. 

In view of the foregoing, it is submitted that applicants' independent claims 1 
and 15 — and thus each of applicants' dependent claims as well — distinguish the 
invention from Shiigi. Reconsideration is requested. 



Office of Ronald D. Slusky 
Registered Patent Attorney 
353 West 56 th St.— Suite 5L 
New York, New York 10019-3775 
Date: 10/15/2004 




Respectfiilly submitted, 
Paul Henry Fuoss et al 



Ronald D. Slusky 
Attorney for Applicant 
Reg. No. 26,585 
(212) 246-4546 
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Email messages are text files formatted to specifications 
outlined in RFC documents that describe how messages 
should be formatted and systems communicate with each other.. 



Emailing in a nutshell 

About E mail Me ssage Format; 

About Multipurpose I nternet Mail Extension? 

AbPJJJLblrtary data encoded message 

About Email Me ssage Structure 

About Mail Servers Protocol 

About Sim ple Mail Transfe r Protocol 

About Post Of fice Protocol 

Abo ut Internet Message Aceessj^nrni 



Email Message Format 

A variety of data like; sound files, images and other binary 
information, etc., are included into email messages—which can 
be formatted by adding specific descriptions to all parts of the 
message. 

For example; messages composed in "rich text" or HTML 
format may Include WAV sound, GIF images attachment, etc.~ 
the message will consist of 3 parts, so that a mall reader (MS 
Outlook or Eudora, etc.) can display the message in "rich text" 
or HTML wfth the image and play the sound WAV file-which are 
not included in normal email messages. 

Hence, a standard format known as MIME (Multipurpose 
Internet Mail Extensions) has been created to describe the 
message parts and mail program conforming to this standard 
will be able to describe its own messages and interpret 
messages created by other systems. 
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driving 
you crazy? 
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r Freeware 




Auto-manage smtp 
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(MIME) Multipurpose Internet Mail Extensions 

MIME encoded messages consist of many parts—each part is 
allowed to be described in detail and some parts encoded. The 
purpose of MIME is to describe the many parts of an email 
message, such as attached sound files and images. 

MIME messages may include a plain text message and a GIF 
image-because GIF image is binary data consisting of 8 bit 
characters. To get the GIF image data to pass through the 
Internet-Base 64 is used to encode the data mto 6-bit 
characters. 
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MIME is also used to annotate part of a message so that the 
receiving mail reader will know what data is stored in the 
message and process it optionally, ie; instead of listing the GIF 
file as a generic attachment—may automatically display it 
instead. 



To top of page 

Message Encoding Binary data 

Message encoding binary data is often represented by 8 bit 
characters and some computers on the Internet are unable to 
transfer data represented by 8 bit characters. Therefore, the 
encoding process must convert 8 bit characters into smaller 
characters for sending across the Internet and then re-convert 
back to 8 bit characters by the receiving computer. 

Base 64, UUencode and Quoted Printable are the most 
popular (there are several types of data encoding). Since many 
Internet email infrastructure was not designed to handle email 
messages containing binary information like file attachments— 
they are converted into a format that is compatible with 
computers on the Internet and this conversion process is called 
encoding. 

Base 64 is generally used to encode binary attachments with 
MIME formatted messages and transforming 8 bit characters into 
6 bit characters-which are compatible with the Internet 
infrastructure (will approximately increase data size to 130%) 
compared to the original. 

UUencode (Unix to Unix) Is an older form of data encoding 
that transforms 8 bit data into characters that are compatible 
with the Internet infrastructure. And most mail systems that 
support Base 64 are also backwards compatible with Uuencode— 
which can only be understood by some older mail systems. 

Quoted Printable encoding is suitable when small portions of 
the message data are stored into 8 bit characters, usually for 
text message that consists of characters less than 8 bits— 
normally for the message body text. 

Quoted Printable encoding is designed to transform 8 bit 
characters into characters compatible with the Internet, similar 
to Uuencode or Base 64 — the difference is that ^Quoted 
Printable" does not convert all the characters of the message, it 
only transforms characters which use more than 7 bits and any 
8 bit characters are split into two or three smaller characters. " 



To top of page 



RFC-822 Message Structure 

Email messages are text files formatted to specifications 
outlined in RFC 8?1 (Request For Comment) documents, that 
describes in detail how messages should be formatted and how 
systems should communicate with each other by following these 
guidelines. 
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An email message has the following parts: RFC-822 Message 
Header and Message Data 

RFC-822 Message Header Is the first part an email messages, 
it specify the many options of the message and includes the 
subject line and headers are not required to be placed in any 
particular order. A MIME formatted message may contain many 
parts and each part may contain its own header and in the 
message data section. 

Example of a Message Header: 

Reply-To: "Service" <service@bouncemailmanager.com> 
From: "Tony" <servrce@bouncemailmanager.com> 
To: "Wendy" <support@mailsbroadcast.com> 
CC: "CEO" <ceo@mallsbroadcast.com> 
Subject: I am getting too many bounce mails. 
Date: Mon, 1 1 Nov 2002 12:38:23 -0400 
MIME-Version: 1.0 

Content-Type: text/plain; charset="iso-8859-r 
Content-Transfer-Encoding: 7bit 
X-Priority: 1 

X-MSMail-Priority: Normal 

X-Mailer: Microsoft Outlook Express 6.00.2600.0000 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 

Reply-To: This is the specified email address that the sender wants the 
recipient to "Reply-To:" Instead of the "From:" email address. 

From: The "From:* email address in the header Is allowed to be 
different from the email address that actually sent the 
message. 

To: Message to be sent to that particular recipient. 

CC: Send a carbon copy of the message to... 

Subject: Message subject of the email. 

Date: Indicates the date and time of the message created and a 
reference to the time zone used to calculate the date and 
time. 

MIME- Indicates the version used for MIME encoding of the 
Versio n : message. 

Content- Header is onry used with MIME messages-to declare the 
Type: general type of data and the subtype specifies a format for 

that type of data. For example: Content-Type: of "text/pJaln"- 

inform the user agent that the data is in plain text format The 

optional "charset" parameter tells the mail reader that the 

message is Intended to be displayed with the "iso-8S59-r 

character set 

Content- Header is only used with MIME messages to specify an 
Transfer- auxiliary encoding that was applied to the data, so that it is 
Encoding: allowed to be to pass through the mail transport 

mechanisms-which may have data or character set 

limitations. 

Custom Headers with an "X-" are added by the program that created 
Headers the message and can be read by a mail reader, therefore 
(X-* Type): any special format specification or information contains in' the 

message— can be taken advantage of— and Ignored, if it is 

not recognized by a mail reader. 

X Pnonty. Custom neader [s qufte popu j ar but different ma j| carters 
may interpret it differently or not at all. For example: usualiy 
roost mail readers set or interpret "4"=/ow "3"=normaf and 
w r=high 
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Message Data following after the message headers is the 
"Message Data"— the composed message body text and any file 
attachment information. Below here is an example of a message 
body without files attachments: 

I need further information about bounce mail manager, 
please send it to service@mailsbroadcast.com 
Thank you :) 

TonyKoh 

mailsbroadcast.com 

http://www.mailsbroadcast.com 

. «<This period indicates the end of the message. 



Example of a message with GIF file attachment encoded with 
MIME and "Quote Printable" message body (GIF encoded with 
Base 64) preceded by an attachment header, which preceded all 
attachments—describing various properties of the attachment. 

This is a multi-part message in MIME format. T° top of page 

=_NextPart_000_0051_01BD9B7E.F01FEA90 

Content-Type: text/plain;charset="iso-8859-1 M 
Content-Transfer-Encoding: quoted-printable 
Message text. 

TonyKoh 

BounceMailmanager.com 
http://www.bouncemailmanager.com 

=_NextPart_000 J)051_01 BD9B7E.F01 FEA90 

Content-Type: image/gif;name= w welcome.gif 
Content-Transfer-Encoding: base64 
Content-Disposition: attach mentjfilename^welco me. grT 
ROIBOCIhAwALAKEWN//// 6VVNUaGgFFFCH5BAEAA 
AAALAAAAADAAsAAAYJhH6tauygkFSFACs= 

=_NextPart_000_0083_01CF9B5S.B012WA70- 

. «<This period indicates the end of the message. 



To top of page 

Mail Servers Protocol 

The most common protocols used by mail server to 
communicate with the Internet are SMTP, P0P3 and IMAP4 to 
(send) receive email messages and distribute and them into 
different recipient unique mailbox. 

Mail servers receive messages via SMTP and email readers 
must send email to a mail server using it. Mail servers using 
POP3 or IMAP4 to send messages, likewise; mail readers must 
use it to receive messages from the mail servers. 

SMTP (Simple Mail Transport Protocol); for sending and 
receiving email messages and POP3 (Post Office Protocol Version 
3); for delivering and retrieving email messages to mail readers, 
example: MS OutJook, Eudora, etc. 
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IMAP4 (Internet Message Access Protocol Version 4); for 
delivering messages to mail readers or to preview and retrieve 
emails from mall servers. 
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(POP3) Post Office Protocol Version 3 

POP3 is a standard client-server protocol for receiving emails. 
The POP3 mail servers listen for email requests via port 110 and 
send email to the requesting party. The client side (ie: Outlook, 
Eudora) mail readers can access (retrieve) emails by issuing a 
predefined set of commands to the mail server. 

A POP3 session is created when a remote user connects to a 
mailbox on the POP3 mail server and ends when the remote user 
disconnects from it. While a session is open, no other user can 
retrieve email from the POP3 mailbox but email can still be sent 
to that account. 

The POP3 clients (Outlook, Eudora) login to the POP3 server 
by sending as clear text the password for the mail account or 
uses APOP authentication— where the password Itself is not sent 
to the remote mail server—using a digest created by the RSA 
MD5 algorithm—based on the password with a unique value sent 
by the POP3 mail server— that changes with connection. 
Therefore, APOP ensures that a different digest will be sent each 
time you log into the server. 
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(IMAP4) Internet Message Access Protocol Version 

4 

IMAP4 is an alternative to POP3 for retrieving emails that 
operate via server port 143 that identify users by account name 
and password. IMAP4 protocol was designed to allow messages 
to be managed on the server. Since the messages remain on the 
server, the protocol is useful for users to access emails from 
various client computers. 

IMAP4 server stores messages in different mailboxes. More 
than one user is allowed to access to an IMAP4 mailbox, 
therefore allowing mailboxes to be shared by multiple users. 
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(SMTP) Simple Mall Transport Protocol 

SMTP is a protocol governing electronic mail transmission and 
reception. A conversation is established with a SMTP server via 
port 25 —After the initial connection, the client ie: Eudora Mail, 
Outlook Express, etc. sends a HELO command followed by the 
domain name, telling the SMTP server whom it Is talking to. The 
SMTP server may terminate the connection if It does not Wish to 
speak to the specified domain. 
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If the HELO command is accepted by the remote server, the 
SMTP client issues a MAIL-FRO M command followed by the 
FROM: address, at this point the SMTP server may terminate the 
connection if it does not wish to speak to the specified domain. 

After the FROM address is accepted, the SMTP client issues a 
RCPT-TO command followed by the address of the intended 
recipient— the SMTP server may terminate the connection if it 
does not wish to speak to the specified address, example: non 
local. 

The SMTP client issues the DATA command to the server and If 
accepted-it then send the message headers followed by blank 
line and the message body, file attachment and finally followed 
by a period to end the message—the SMTP server acknowledges 
receipt— and the SMTP client send a QUIT command and 
terminate the conversation. 
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Extended SMTP 

ESMTP consists of several extensions (all optional) to the basic 
SMTP protocol which may or may not be supported by mail 
servers. Whereas, normal SMTP Involves several fragments of 
data being sent from the client to the mail server. After each 
fragment is sent, the client waits for the mall server 
acknowledgement repJy and then the client sends the next 
fragment, and so on. Therefore, a time is wasted while waiting 
for the server to return a response. 

Pipelining extension 

Pipelining can send messages faster by allowing the client to 
batch several fragments of data together and sending them all at 
once, and the server only need to acknowledge with one reply 
for the combined set of data. Since the fragments and 
acknowledgements are combined, the client spends less time 
waiting for the server to respond. 

Delivery Status Notifications 

DSN extension supported SMTP servers allow greater control of 
the notification process by specifying when and how notifications 
are sent. DSN extensions also allow for an "Envelope ID" to be 
included in the outbound message, which is returned as a MIME 
part of the delivery status notifications— therefore, allowing client 
applications to match delivery status notifications to the original 
message. 

An example MIME part to a DSN message with the Envelope ID 
specified as 3112394 
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-FAA10845.816082428/maN.domain.com 
Content-Type: message/deltvery-status 

Original-Envelope-Id: 31 12394 
Reporting-MTA: dns; maiLdomain.com 
Received-From-MTA: DNS; tony.bouncemailmanager.com 
Arrival-Date: Tue, 10 Dec 2002 12:37:15-0900 (EST) 

Original-Recipient: rfc822;tony@bouncemailmanager.com 
Finaf-Recipient: RFC822; xxx0021@mail.domain.com 
Action: delivered (to mailbox) 
Status; 2.1.5 

Last-Attempt-Date: Tue, 10 Dec 2002 1 2:37:43 -0900 (EST) 
- FAA1 0845.81 6082428/mail. domain. com 
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